The present invention relates to computer networks and, more specifically, to a system and method for transferring multiple data types within a single operation in a computer network.
Data communication in a computer network involves the exchange of data between two or more entities interconnected by communication links. The entities are typically software programs executing on hardware computer platforms, such as nodes; in particular, communication software executing on the nodes correlate and manage data communication with other nodes. The nodes typically communicate by exchanging discrete packets or frames of data according to predefined protocols. In this context, a protocol consists of a set of rules defining how the nodes interact with each other. Collectively, these hardware and software components comprise a communications network and their interconnections are defined by an underlying architecture.
Modem communications network architectures are typically organized as a series of hardware and software levels or xe2x80x9clayersxe2x80x9d within each node that interact to format data for transfer over the network. Predetermined services are performed on the data as it passes through each layer and the layers communicate with each other by means of the predefined protocols. The lower layers of these architectures are typically implemented in hardware and firmware, whereas the higher layers are generally implemented in the form of software running on the nodes attached to the network. Examples of such communications architectures include the the Internet communications architecture and the Systems Network Architecture (SNA) developed by International Business Machines (IBM) Corporation.
SNA is a mainframe-oriented network architecture that includes services generally similar to those defined in the Internet communications architecture. An SNA network consists of nodes and links, wherein the nodes are network components containing protocol implementations and the links are transmission facilities that carry data between two nodes configured to operate a data link control procedure. Examples of such nodes include a host mainframe computer, a control unit and an input/output (I/O) device that is provides a user interface to the network. In one embodiment of the SNA network, the control unit and I/O device may be combined within a node, such as a workstation, and in another embodiment, the control unit may be independent of the workstation and include a router to enable routing of data through the network to destination nodes, such as computers and/or workstations functioning as end stations.
The host is typically connected to the control unit through a high-performance communication subsystem called a mainframe channel. The channel comprises a plurality of components including an intelligent processor (i.e., channel CPU) that manages the protocol over a communications link and controls transfer of data between host (main memory) storage and I/O devices directly attached to the control unit. To that end, a channel may use one or more channel paths as the actual links between a host and the control unit. Channel paths include physical transmission links between the channel and control unit; examples of channel paths include bus-and-tag and enterprise system connection (ESCON) channel paths. Moreover, each I/O device is represented by a subchannel. A subchannel is similar to a virtual circuit in that it provides information about the associated I/O device and its attachment to the channel.
To transfer data in connection with an I/O operation, the channel CPU executes channel command words (CCWs) once started by a start subchannel operation. The start subchannel command is issued by the host CPU to instruct the channel CPU as to the location of a channel program; this command also specifies the subchannel on which the channel program should execute. The software entity within the host mainframe that creates the channel program is a Tranmission Control Protocol/ Internet Protocol (TCP/IP) process, which is schematically illustrated as layers of a typical Internet communications protocol stack. Protocol stacks and the TCP/IP reference model are well-known and are, for example, described in Computer Networks by Andrew S. Tanenbaum, printed by Prentice Hall PTR, Upper Saddle River, N.J., 1996.
The channel program consists of a collection of CCWs; the CCWs are the actual I/O commands (read, write, status, etc) that cause information to flow between the host and an I/O device. The control unit interprets these CCWs and adapts them to fit the characteristics of different I/O devices. Upon issuing a start subchannel operation, the host CPU is released to pursue other processing while the channel organizes the data referenced by the channel program and synchronizes its transfer between the I/O device and main memory.
Communication between a channel and control unit is typically governed by various protocols; a protocol originally developed by IBM Corporation for improving the efficiency of data communication between a host computer and a control unit is the common link access to workstation (CLA W) protocol. CLAW is a mainframe channel protocol that is not used with medium access control addressing and, thus, is generally used to send IP packets (in IP datagram mode) or TCP-socketed traffic, such as socket requests and responses (in IP socket offload mode).
A socket is essentially an interface between an application layer and transport layer of a protocol stack that enables the transport layer to identify which process it must communicate with in the application layer. For example, a socket interfaces to a TCP/IP protocol stack via a set of application programming interfaces (API) consisting of a plurality of entry points into that stack. Applications that require TCP/IP connectivity typically utilize the socket API to interface into the TCP/IP stack. For a connection-oriented protocol such as TCP, the socket may be considered a session; however, for a connectionless protocol such as IP datagram using the User Datagram Protocol (UDP), the socket is an entity/handle that the networking software (protocol stack) uses to uniquely identify an application layer end point, typically through the use of port numbers. The socket offload protocol provides such a socket interface.
In a CLAW environment, the control unit is coupled to a CLAW device, which is a software entity executing on a node, such as a workstation; in many CLAW implementations, the control unit and workstation are combined within the control unit. Data communication takes place over a channel via the exchange of data packets between the control unit and host. The CLAW protocol achieves data communication efficiency, in part, by avoiding host CPU interrupts during I/O channel operations through the continuous execution of channel programs over two subchannels: one for write operations and one for read operations.
Two CLAW devices are typically spawn within the control unit to interface with the host mainframe: one process (the write device) that controls write operations over the write subchannel and the other process (the read device) that controls read operations over the read subchannel. Data received from the network is typically provided to the read device and data arriving from the channel interrupt routine is provided to the write device. The host generally does not have corresponding processes for these two devices; rather it has control block structures that are specific to each device and that contain state information about the status of the devices.
Logical links are defined in CCWs for read and write operations to establish multiple logical connections within each subchannel directed to different applications executing on the host and control unit. In fact, a main goal of the CLAW protocol is to enable efficient switching among applications specified by the logical links to facilitate data transfers to appropriate outbound interfaces (e.g., FDDI or Ethernet). Accordingly, the logical links are a way to multiplex within a subchannel.
The CLAW protocol generally defines (i) command codes associated with CCWs and (ii) the order in which those command codes are specified in a CCW chain. A logical link number (0-31) is embedded in the CCW command code, wherein number 0 is reserved for a control link and numbers 1-31 specify application-to-application (data) links. The control link path is part of a read/write subchannel pair dedicated to CLAW protocol communication. The host CPU builds a channel program comprising a chain of CCW data structures in main memory that contain instructions (e.g., read, read header, status modifier (SMod), write). These instructions are then executed in accordance with the CLAW protocol.
The CLAW protocol also defines two primary sets of control flows over the control link: system validate/system validate response and connection establishment sequences. These CLAW connection protocol flows are well-known and described in AIX Version 3.2, Enterprise Systems Connection Adapter: User""s Guide and Service Information, IBM, 1993. Broadly, stated, the system validate/system validate response control flows are manifested as message packets that propagate over the control link, passing information as data within a predetermined packet format. Before sending data, a system validate/response message flow occurs over the control link to verify the names of the control unit and host.
The control unit and host names are configuration parameters used to ensure that the host is communicating with a proper control unit application. If the control unit (or host) name contained in the system validate message is incorrect, a control application provides a non-match return code in the system validate response message along with the expected name. Upon completion of the system validate/response exchange, the control link (0) is established and the host is xe2x80x9cawarexe2x80x9d of the application to which it is connected.
However, logical data links still need to be established for application-to-application data communication.
In order to establish a data link between two communicating applications, a connection request sequence is executed between the host and control unit. A control application resident on the host is typically responsible for initiating the connection request sequence to establish logical links (1-31) for data transfers between applications. A logical link is essentially a means for classifying the type of data transferred between the host and control unit. A channel adapter within the control unit controls logical link assignments for applications executing on the unit. The connection request sequence operates to establish the actual links used for host application-to-control unit application data transfers; once established, various types of data flow over these application-application links (e.g., a TCP/IP application has IP packets flowing over the link). The CCW for each CLAW operation defines the logical link and the logical link, in turn, defines the type of data; however, only a single type of data is supported for each channel operation.
For host originated connections, the connection request originates in the host over control link 0 and is sent to the channel adapter which selects an available link and alters the connection request to reference that link. The adapter then passes the connection request onto the targeted application of the control unit. The channel adapter sends the connection response back to the host over the control link. If the control unit does not agree with the name of its application specified in the request, it returns a disconnect command; otherwise, a connection confirm response is provided to the host and the link is ready for data transfer.
The host CPU then issues a start subchannel (SSCH) command to the channel CPU instructing that latter CPU to initiate an I/O operation to the targeted application. The channel CPU executes the SSCH command, which points to the beginning of a CCW chain of a channel program in main memory. In the case of a read (or write) channel program, the channel CPU gains control of the program, reads each CCW in sequence and executes it to initiate the flow of data (IP packets), along with the CCW command code, over the physical channel interface wire and through the control unit to the targeted application.
The size of an IP packet is limited to a maximum transfer unit (MTU) size of the channel interface. Typically, the MTU for the interface is 4096 (4K) bytes and the maximum amount of data of a CLAW read/write operation is 4K bytes. Thus, each data block handled by the CLAW protocol (i.e., a CLAW data block) contains one IP packet that is limited in size by an MTU of 4K bytes. If it is necessary to send blocks of data that are larger than 4K bytes using the CLAW protocol, the blocks may be chained together by a xe2x80x9cmore-to-comexe2x80x9d indicator.
For example, the CLAW protocol may be employed to transmit TCP-socketed data traffic in accordance with an IP socket offload implementation. The data is organized as 4K byte socket offload request/response messages that are linked together with the more-to-come indicator to create a logical chain of data. A socket header is located at the beginning of the entire xe2x80x9cmore-to-come chainxe2x80x9d of offload messages and defines the user application for the chained data. However, each individual offload message originates at the same socket. A high level overview of the IP socket offload protocol is described in IBM TCP/JP for MVS: Offloading TCP/IP Processing, Version 3, Release 2, IBM 1992, 1997.
The minimum number of CCWs needed to read an IP packet includes a read operation of the CLAW data block, a read operation of the CLAW header and a SMod operation. The actual data of the packet is read during the read operation of the 4K byte CLAW block; all other operations (such as read header, SMod and read FF operations, the latter of which invokes an interrupt) are overhead. Accordingly, an objective is to avoid additional overhead operations, such as the read FF operation.
For each received CCW command code, the control unit responds with either xe2x80x9cYesxe2x80x9d, xe2x80x9cInvalid Commandxe2x80x9d or xe2x80x9cBusyxe2x80x9d. A yes response is followed by execution of the CCW command. Either the channel or the control unit can terminate an I/O channel operation. Termination implies that the targeted application has received or provided all data associated with the I/O operation and no longer requires channel facilities. Control unit initiated I/O termination indicates that the channel operation has completed and the control unit is ready to execute another operation.
As noted, the CCWs generally define channel processing and, indirectly, activity on the physical interface medium. Depending on the type of interface, particular messages are exchange over the wires coupling the host mainframe and control unit. In the case of an ESCON interface, for example, there are a number of specific frames that flow over the physical interface medium when the channel CPU executes CCWs associated with a write operation. The ESCON frames comprise (i) a command frame including a write operation, (ii) a command response frame which is an acknowledgment that the frame is valid, and (iii) an accept command response frame which is used in the event of an error in the command response frame. Thereafter, data frames flow from the mainframe to the write device of the control unit followed by data request frames from the control unit to the mainframe.
In general, it takes approximately 200 microseconds to transfer only the data frames of a 4K byte CLAW data block at a signaling rate of 200 megahertz (MHz). In addition, the overhead associated with the non-data frame exchanges may consume approximately 80 microseconds for a subtotal of 280 microseconds to complete the actual write operation. Yet, there is also the read FF operation associated with the CCW program directed to the write device, which operation requires approximately 50 microseconds of xe2x80x9cpure overheadxe2x80x9d to transfer 1 byte of information. Thus, the write channel operation requires 130 microseconds of overhead and 200 microseconds of data transfer, or approximately 40 percent of bandwidth consumed by overhead.
The overhead associated with the read device channel program is greater because there is a minimum of three (3) operations required: two read operations and one write operation (the SMod operation). Using the same generalization as in the write channel operation, the read data operation takes approximately 50 microseconds, the read header operation takes approximately 50 microseconds and the SMod operation takes approximately 80 microseconds for a total of 180 microseconds for every 200 microseconds of data transfer. This results in approximately 50 percent of bandwidth attributable to ESCON and CLAW overhead.
In both cases described above, it is assumed that the data transfers occurred at 4K byte optimal lengths, resulting in 200 microseconds of data transfer for either 130 or 180 microseconds of overhead. A practical situation involves IP datagram mode and, in particular, the use of TCP acknowledgments (ACKs), each of which comprises 64 bytes of data. For this less optimal case, 3.2 microseconds of data transfer is required to send the ACK. Again, either 180 or 130 microseconds of overhead is required for the 3.2 microsecond data transfer, resulting in approximately 90 to 98 percent of bandwidth consumed with ESCON and CLAW overhead. The present invention is directed to substantially increasing the data-to-overhead transfer ratio or, in other words, substantially lowering the percentage of bandwidth consumed by ESCON and CLAW overhead.
The invention relates to an enhanced CLAW packing protocol that supports the transfer of multiple data types from different sockets/sessions within a single channel operation between a host mainframe and a control unit of a computer network. According to the invention, multiple logical sublinks are created under a single packed CLAW logical link, wherein each sublink may transport a uniquely identifiable data type as a message from a socket/session. The messages are then concatenated within a single CLAW data block for transfer over a channel coupling the host and control unit. In addition, the invention increases the maximum size of the CLAW block for each channel operation.
Specifically, the enhanced CLAW packing protocol defines sublink 0 for transporting novel packed control messages used to establish non-zero sublinks, each of which may transport a packed data message of a particular data type within the same channel operation. Where the conventional CLAW protocol allows the transfer of only one message, such as an Internet protocol (IP) datagram, of a particular data type (e.g., either checksummed or non-checksummed) per CLAW block, the enhanced CLAW packing protocol described herein allows the transfer of multiple IP datagrams of various data types (checksummed, non-checksummed and/or any other data type) within the same block. The enhanced protocol also extends the maximum CLAW block size from, e.g., 4K bytes to 64K (actually 64Kxe2x88x921) bytes for each channel operation.
In the illustrative embodiment, the packed CLAW link is established in connection with conventional CLAW initialization procedures, such as system validation and connection request flows. Upon formation of the packed link, a packing control sublink is provided for exchanging the packed control messages between the host and control unit. The enhanced protocol manifests as an exchange of these packed control messages to further establish the sublinks xe2x80x9cunderneathxe2x80x9d the packed link. Thereafter, data is transferred over the packed CLAW link as a series of packed data messages within a packed CLAW block.
According to an aspect of the present invention, the packed data message embodies a novel format including a header, data and padding. The padding terminates the packed data message in a manner that enables the header of a next packed message to assume a xe2x80x9cnaturalxe2x80x9d alignment. The header comprises a length field that specifies a boundary of the packed message to thereby distinguish the message from other packed messages of the CLAW block. The header further comprises a sublink field containing a sublink number that identifies a particular type/logical link of the data carried in the message. The novel packed data message format allows independent processing of each of the concatenated messages regardless of whether the messages originate from different socket/sessions and contain different data types within/without those sockets/sessions.
Advantageously, the invention enhances the CLAW protocol to enable concatenation of multiple messages from different sockets/sessions into a single channel block for transfer over the channel to thereby reduce overhead on the channel for the total number of transferred messages.